The standardization organizations such as the 3rd Generation Partnership Project (3GPP), 3GPP2, International Telecommunication Union Telecommunication Standardization Sector (ITU-T), Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN) are developing standards about the Next Generation Network (NGN), and have basically defined the IP Multimedia Subsystem (IMS) as a core network of the next-generation fixed and mobile networks. In the network evolution process, the access technologies and service provision are diversified, the bearer is Internet Protocol (IP)-based, and the core network is uniformly undertaken by the IMS.
Currently, the user identity for use in an IMS network may be an IP Multimedia Public User Identity (IMPU) or an IP Multimedia Private User Identity (IMPI). The user identity is stored in a Home Subscriber Server (HSS) in subscription mode. When the user performs a relevant service operation, a relevant entity such as an Interrogating Call Session Control Function (I-CSCF), a Serving Call Session Control Function (S-CSCF), and an Application Server (AS) in the network obtains the subscription data of the relevant user from the HSS by using the user identity.
In the IMS, the relation between one user identity and another, and the relation between the user identity and the subscription data are: One IMS subscription includes all subscription information of a subscriber that may be transmitted on a Cx interface; multiple IMPIs may exist under an IMS subscription, but one IMPI belongs to only one IMS subscription; one IMPI may include multiple IMPUs, and one IMPU may be shared by multiple IMPIs. That is, a one-to-many relation exists between the IMS subscription and the IMPI, and a many-to-many relation exists between the IMPI and the IMPU. A multi-registration concept is introduced in order for a user to use a subscription identity pair (IMPI, IMPU) through one User Equipment (UE) based on different access technologies. To put it simply, multi-registration enables a user to use a subscription identity pair (IMPI, IMPU) and register multiple contact addresses simultaneously. On every occasion of registering the UE, one of the contact addresses is registered. The UE adds a new “reg-id” parameter to the contact header field of the Session Initiation Protocol (SIP) REGISTER message to uniquely identify a registration in the multi-registration. When the UE registers a (IMPI, IMPU) pair with the S-CSCF simultaneously through multiple access technologies, the S-CSCF stores multiple registration records related to the (IMPI, IMPU) pair simultaneously. Each registration record has a different “reg-id”. In the subsequent re-registration, the corresponding “reg-id” keeps unchanged. When the UE that supports multi-registration initiates deregistration, if all multi-registration addresses related to the (IMPI, IMPU) pair need to be deregistered, the UE needs to add “*” into the Contact header field; if one registration address in the multi-registration needs to be deregistered, the “Contact” header field needs to include the “reg-id” applied at the time of registering the UE.
To still provide a service for the user after the S-CSCF is restarted or faulty, the registration information of the user needs to be backed up in the HSS. After the S-CSCF is restarted or faulty and a new S-CSCF is selected, the user registration information can be obtained from the HSS so that the service is still available to the user. The HSS backs up the user registration information after receiving a Server Assignment Request (SAR) message that carries the user registration information from the S-CSCF. The S-CSCF obtains the user registration information by receiving a Server Assignment Answer (SAA) that carries the user registration information from the HSS. One (IMPI, IMPU) pair corresponds to a copy of registration backup data, and the registration backup data is stored in the HSS transparently.
Scenario 1: After receiving an initial registration request from the UE, the S-CSCF authenticates the UE successfully, and sends an SAR to the HSS to request the user profile. The SAR carries the registration information of the UE, including at least the contact address and information in a path header field. The HSS finds that the SAR is related to the initial registration (SAT=REGISTRATION) but the (IMPU, IMPI) pair has been registered, and the HSS stores the backup data related to the IMPI. Therefore, the HSS returns an SAA that carries the relevant registration backup data previously stored on the HSS to the S-CSCF, without using the registration backup data carried in the SAR to replace the stored backup data. According to the current registration information of the UE and the registration backup data returned by the HSS, the S-CSCF updates the registration backup data, for example, adds the contact address and path information related to this registration of the UE into the backup data, and sends an SAR (SAT=RE_REGISTRATION) message to the HSS again to update the backup data stored in the HSS.
The reason for the foregoing operations is that the registration backup data is stored in the HSS transparently, namely, the HSS does not parse the registration backup data in the SAR. After the S-CSCF is restarted or faulty and a new S-CSCF is selected, the S-CSCF stores no user data or the previous user data is not trustworthy. The foregoing operations are intended to prevent that: In a multi-registration scenario, after the S-CSCF receives a registration message from the UE such as a registration message for initial registration in the multi-registration, the SAR carries the registration backup data to the HSS, and such registration backup data replaces the registration backup data stored in the HSS in the previous registration (namely, another initial registration in the multi-registration), which leads to loss of some backup data and unavailability of the user registration backup data in the subsequent failover of the S-CSCF.
Scenario 2: The S-CSCF receives a deregistration message “REGISTER” from the UE. If the (IMPU, IMPI) pair related to the deregistration is not registered in the S-CSCF, the S-CSCF sends an SAR (SAT=NO_ASSIGNMENT) message to the HSS to request the relevant registration backup data. Afterward, the S-CSCF compares the contact address in the received backup data with the contact address carried in the deregistration message from the UE. If the two contact addresses are the same or the contact address from the UE carries “*”, the S-CSCF sends a deregistration request SAR (SAT=USER_DEREGISTRATION) to the HSS to clear the registration backup data stored in the HSS. If the two contact addresses are different, the S-CSCF sends an SAR (SAT=RE_REGISTRATION) message that carries the updated user registration backup data to the HSS to update the user registration backup data in the HSS.
The foregoing operations are intended to prevent that: In a multi-registration scenario, after the S-CSCF is restarted or faulty and a new S-CSCF is selected, the S-CSCF receives a deregistration message from the UE. The deregistration message requests deregistration of a contact address in the multi-registration. If the S-CSCF sends a deregistration request SAR (SAT=USER_DEREGISTRATION) to the HSS directly, the HSS clears the stored registration backup data, which leads to loss of some backup data and unavailability of the user registration backup data related to the (IMPI, IMPU) pair in the subsequent failover of the S-CSCF.
In the process of implementing the present invention, the inventor finds at least the following problems in the prior art: The technical solution described in scenario 1 above recovers the multi-registration information without loss after the S-CSCF serving the user is faulty, but the S-CSCF and the HSS perform the SAR/SAA operation twice for all initial registrations. For the UE or S-CSCF that does not support multi-registration, in every conventional initial registration process of the UE, two SAR interactions still be performed between the HSS and the S-CSCF, which increases the unnecessary signaling load between the HSS and the S-CSCF and unnecessary data processing between the HSS and the S-CSCF. The solution provided in scenario 2 above can recover the registration backup data of multi-registration without loss after the S-CSCF is faulty and the registration backup data is cleared in the HSS in the case that the UE deregisters a contact address. The SAR/SAA interaction still is performed twice between the HSS and the S-CSCF because of multi-registration. Such interactions are unnecessary for the UE that does not support multi-registration. In conclusion, in the process of backing up the registration information in the prior art, the SAR/SAA signaling interaction is performed twice between the HSS and the S-CSCF due to multi-registration. For the UE or S-CSCF that does not support multi-registration, the unnecessary signaling load and unnecessary data processing between the HSS and the S-CSCF are increased, and therefore system resources are wasted seriously.